-
-
Notifications
You must be signed in to change notification settings - Fork 4k
bevy_reflect: Use active_types
instead of active_fields
where appropriate
#19922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
active_types
instead of active_fields
where appropriate
Best reviewed one commit at a time. It looks like this repo might squash-and-rebase to land PRs? I often do multi-commit PRs so I'll give it a try here, see how it pans out. |
Yep, we use squash-on-merge, so the multi-commit approach is really helpful here. |
It's a shame that squashing loses the separation in the history. It also decreases the value of bisection, if bugs are introduced. |
active_types
instead of active_fields
where appropriateactive_types
instead of active_fields
where appropriate
Indeed :) However, it is much easier on novice contributors, and it allows us to ensure that every commit in the history compiles via CI checks, allowing for easier bisection and examination of history. |
Oh, interesting. I think I still prefer having the smaller chunks in the history, but reasonably people could disagree and Bevy ain't my project :) |
@nnethercote can you resolve merge conflicts please? |
This could have been part of bevyengine#19876, which deduplicated the fields. It's also simpler and more efficient to keep the (short-lived) active types as an `IndexSet<Type>`, and avoid converting them to a `Vec<Type>` and then a `Box<[Type]>`.
Instead of `active_fields`. This makes it match `ReflectStruct`, and avoids redundant calls within the generated `register_type_dependencies` when the same type is used in multiple enum variant fields.
I rebased. Should be good to go. |
Objective
Follow on fixes for #19876, using
active_types
instead ofactive_fields
where appropriate.Helps a tiny bit with #19873.
Solution
Testing
I checked the output of
cargo expand
and rancargo run -p ci
.